Currently, when setting the thread stack size fails, it would be rounded
up to the nearest multiple of the page size and the code asserts that
the next call to pthread_attr_setstacksize succeeds.

This may be true for glibc, but it isn't true for musl, which not only
enforces a minimum stack size, but also a maximum stack size of
usize::MAX / 4 - PTHREAD_STACK_MIN [1], triggering the assert rather
than erroring gracefully.

There isn't any way to handle this properly other than bailing out and
letting the user know it didn't succeed.

[1]: https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_attr_setstacksize.c#n5

Signed-off-by: Jens Reidel <[email protected]>

…eadId`

Reference: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getcurrentthreadid

In the process, fix a race condition, by never truncating or writing to
the file unless we currently hold the lock.

Extracting the Rust tarballs doesn't require this.

…eck compiler`

… not stage selection

equivelent -> equivalent
recommeded -> recommended

When a UI test runs a compiled binary and an error/forbid pattern
check fails, the failure message previously only showed compiler output,
hiding the executed programs stdout/stderr. This makes it harder to
see near-miss or unexpected runtime lines.

…t,rust-analyzer}`

…r=jhpratt

std: thread: Return error if setting thread stack size fails

Currently, when setting the thread stack size fails, it would be rounded up to the nearest multiple of the page size and the code asserts that the next call to `pthread_attr_setstacksize` succeeds.

This may be true for glibc, but it isn't true for musl, which not only enforces a minimum stack size, but also a maximum stack size of `usize::MAX / 4 - PTHREAD_STACK_MIN` [1], triggering the assert rather than erroring gracefully.

There isn't any way to handle this properly other than bailing out and letting the user know it didn't succeed.

[1]: https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_attr_setstacksize.c#n5

…ouxu

Reduce usage of `compiler_for` in bootstrap

While working on refactoring/fixing `dist` steps, I realized that `build.full-bootstrap` does much more than it should, and that it its documentation is wrong. It seems that the main purpose of this option should be to enable/disable stdlib/compiler uplifting (https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Purpose.20of.20.60build.2Efull-bootstrap.60/with/533985624), but currently it also affects staging, or more precisely which compiler will be used to build selected steps, because this option is used in the cursed `compiler_for` function.

I would like to change the option it so that it *only* affects uplifting, and doesn't affect stage selection, which I (partially) did in this PR. I removed the usage of `compiler_for` from the `Std` and `Rustc` steps, and explicitly implemented uplifting, without going through `compiler_for`.

The only remaining usages of `compiler_for` are in dist steps (which I'm currently refactoring, will send a PR later) and test steps (which I will take a look at after dist). After that we can finally remove the function.

I tried to document the case when uplifting was happening during cross-compilation, which was very implicit before. I also did a slight change in the uplifting logic for rustc when cross-compiling. Before, we would attempt to uplift a stage1 rustc, but that is not really a thing when cross-compiling.

r? `@jieyouxu`

…-windows, r=Kobzol

ci: clean windows disk space in background

…heck-split, r=jieyouxu

Split codegen backend check step into two and don't run it with `x check compiler`

This reduces the amount of work that is done during `x check compiler`. We still check both backends during `x check` by defaut, even if they are not in `rust.codegen-backends`, as just checking them shouldn't require expensive preparations, like building GCC.

r? `@jieyouxu`

…=petrochenkov

Deduplicate -L search paths

For each -L passed to the compiler, we eagerly scan the whole directory. If it has a lot of files, that results in a lot of allocations. So it's needless to do this if some -L paths are actually duplicated (which can happen e.g. in the situation in the linked issue).

This PR both deduplicates the args, and also teaches rustdoc not to pass duplicated args to merged doctests.

Fixes: rust-lang#145375

Windows: Replace `GetThreadId`+`GetCurrentThread` with `GetCurrentThreadId`

Reference: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getcurrentthreadid

…, r=clubby789

bootstrap: Reduce dependencies

Eliminate the `fd-lock` dependency by using the new native locking in std.

Eliminate the `xattr` dependency by turning off a feature flag in `tar`, since
the tarballs that we extract with bootstrap don't need it.

… r=lqd

Fix typos in bootstrap.example.toml

Founds these small typos while looking around.

`equivelent` -> `equivalent`
`recommeded` -> `recommended`

cheers :)

…r=lqd

Fix wrong spans with external macros in the `dropping_copy_types` lint

This PR fixes some wrong spans manipulations when external macros are involved.

Specifically we didn't make sure the spans had the same context, which kind-of make our spans manipulations go wrong and produce weird spans. We fix that by making sure they have the same context.

Fixes rust-lang#145427

Enhance UI test output handling for runtime errors

When a UI test runs a compiled binary and an error/forbid pattern check fails, the failure message previously only showed compiler output, hiding the executed programs stdout/stderr. This makes it harder to see near-miss or unexpected runtime lines.

Fixed rust-lang#141531
Supersedes rust-lang#141977

Autolabel `src/tools/{rustfmt,rust-analyzer}` changes with `T-{rustfmt,rust-analyzer}`

Make e.g. rust-lang#144323 more obvious who should be reviewing it and easier to filter.